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Abstract 


This document defines a content media feature schema for Internet 
fax. 


It is a profile of the media feature registration mechanisms [1,2,3] 
for use in performing capability identification between extended 
Internet fax systems [5]. It replaces and updates the feature schema 
defined in RFC 2531. 


Table of Contents 


LS TNEKOdUCČETON Lp inda iausi a a aa M ET da bene NSA 2 
1 „1. Organization of this doeumént 4 eko k eee o 3 
1.2 Terminology and document conventions ................. 3 
13 DESCUSSLON Of this document s oss sti k pe e k Se 4 

2, Fax feature schema, syntax - o's ere bd alee ew eid tek a Sale Ea ES 4 

3, Internet fax feåture- tags sura k eae ee oe Bae oie Sees oe 4 
Suma Tmage- Se KLIN Na ae etn Gh 5 DS aie agi ean AG 5 
22 RE SO LUE POMS setet varer Sele aent 5 
3.53 Media type. tee cove ns la a a La Loe Sen k Serie tet 6 
Sr Paper STE Sars Ss ST er a ot Gee aude tele 6 
Jo "COLO LOAPabilTep Les ui. dete. arai Mei atin Ge Salas see ee 7 
3263 COLOT MODS]. Hanse Ses REN ee 8 
357 Image: Coding soens e ee k e er STEK See k E S 11 
3149 „MRO IMO AE: r salai arų Nas S as SPT SN SENT 12 

Ave EXAMPLES: Laser ae is doen k Šis klas Ske Seed hs sae ee Sa ees 13 
4.1 Simple mode Internet fax system .................... 13 


Klyne & McIntyre Standards Track [Page 1] 


RFC 2879 Content Feature Schema for Internet Fax (V2) August 2000 


4.2 High-end black-and-white Internet fax system......... 14 
4.3 Grey-scale Internet fax system .............-...2-06- 14 
4.4 Full-color Internet fax system (JPEG only) .......... 15 
4.5 Full-color Internet fax system (JPEG and JBIG) ...... 16 
4.6 Full-color Internet fax system (MRC) ................ 17 
4.7 Sender and receiver feature matching ................ 19 
Sis: LANA Considerations Lisinskas ii ei dere ete hs doe Se eel eee es 21 
6:5. «Security Considerations id otis asses Wea a hale Eee Rate SE Als ee lis 21 
6.1 Capability descriptions and mechanisms .............. 21 
632. SPECGITTG threats aioe fie tiers lee eee i eee ee 21 
Toe Acknowledgements „is ru kreida wea sag eS ar a a eee eee Se ee ares 22 
85 References” Lis kurs She eed ee te es ae a aig 22 
9s Authors” -AdAESSSĖS 4 Sania Shove tas ad sø ses eas ble td Pye ment 24 
Appendix A: Feature registrations ........ cee ee ee eee ee ee eee 25 
Al, ImageSize Astikas SNe eS BW i k SE he A a SE k es 25 
A.2 Resolution ASPECT råtio sses. sees ae e sir kis k se 27 
Ais 3 COLO LEVELS: Kusiai aa rs k Bie ibs ee a i Suge 28 
APA COLO Space - > Litas Kiss SAT 30 
AD CIELAB: color illuminant 45 idus etd k eed Bete ds 33 
A6 CIELAB Color depth 4 A ėda a a råe a p a a N 35 
AIT CECTELAB: COLor gamut. At Maaso ve: kau ates d elie Gass 37 
Aco Image file Structure sns a si ete ar saks 39 
A.9 Image: data Coding seikass ius ai i se 41 
A.:10 Image coding Const rawness) sous eels hee: sans see kad a 43 
All. JBTG- SET TPS 2S TAS: ss ka Sues oo a a karse i eae where 44 
AVIA Image -interleave Grušas Soe a 46 
A. 13: -Corlor Subsåmpling os ka ias Ke cae kr is i i 47 
A.. 14, MRC availability and mode. cser d dk ee das k k anelse 49 
Asko (MRC maximum Stripe 5126 sisao suk Aa REG es 50 
Appendix B: TIFF mode descriptions ..............-.---.-.---- 52 
Appendix, Ce. “Changes: From REG 2531 sre snr esaer e seede etn 57 
FulL CGöpyright Statement | Ki utse dia na a Sab es rekene 58 


1. Introduction 


This document defines a content media feature schema for Internet 
fax. 


It is a profile of the media feature registration mechanisms [1,2,3] 
for use in performing capability identification between extended 
Internet fax systems [5]. It replaces and updates the feature schema 
defined in RFC 2531. 


The media feature description mechanisms do not describe any specific 
mechanisms for communicating capability information, but do presume 
that any such mechanisms will transfer textual values. In 
conjunction with this feature schema, they specify a textual format 
to be used for describing Internet Fax capability information. 
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The range of capabilities that can be indicated are based on those 
covered by the TIFF file format for Internet fax [7] and Group 3 
facsimile [6]. A companion document [4] describes the relationship 
and mapping between this schema and Group 3 fax capabilities. 


1.1 Organization of this document 


Section 2 specifies the overall syntax for fax feature descriptions 
by reference to the media feature registration and syntax documents 
BESAR 


Section 3 enumerates the feature tags that are to be recognized and 
processed by extended Internet fax systems, according to their 
capabilities. 


Appendix A contains additional feature tag registrations for media 
features that are specific to fax and for which no applicable 
registration already exists. These are presented in the form 
prescribed by the media feature registration procedure [1]. 


1.2 Terminology and document conventions 


The term "extended Internet fax system" is used to describe any 
software, device or combination of these that conforms to the 
specification "Extended Facsimile Using Internet Mail" [5]. 


"capability exchange" describes any transfer of information between 
communicating systems that is used to indicate system capabilities 
and hence determine the form of data transferred. This term covers 
both one-way and two-way transfers of capability information. 


"capability identification" is a particular form of capability 
exchange in which a receiving system provides capability information 


to a sending system. 


"capability description" is a collection of data presented in some 


specific format that describes the capabilities of some communicating 


entity. It may exist separately from any specific capability 
exchange mechanism. 


NOTE: Comments like this provide additional nonessential 
information about the rationale behind this document. 
Such information is not needed for building a conformant 
implementation, but may help those who wish to understand 
the design in greater depth. 
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1.3 Discussion of this document 
Discussion of this document should take place on the Internet fax 
mailing list hosted by the Internet Mail Consortium (IMC). Please 
send comments regarding this document to: 


ietf-fax@imc.org 


To subscribe to this list, send a message with the body ’subscribe’ 
to "ietf-fax-requesttimc.org". 


To see what has gone on before you subscribed, please see the mailing 
list archive at: 


http://www.imc.org/ietf-fax/ 
2. Fax feature schema syntax 
The syntax for the fax feature schema is described by "A syntax for 
describing media feature sets" [2]. This in turn calls upon media 
feature tags that may be registered according to the procedure 


described in "Media Feature Tag Registration Procedure" [1]. 


NOTE: Media feature registration provides a base 
vocabulary of features that correspond to media handling 


capabilities. The feature set syntax provides a 
mechanism and format for combining these to describe 
combinations of features. This memo indicates those 


features that may be associated with extended Internet 
fax systems. 


3. Internet fax feature tags 


This section enumerates and briefly describes a number of feature 
tags that are defined for use with extended Internet fax systems and 
applications. These tags may be used also by other systems and 
applications that support corresponding capabilities. 


The feature tags presented below are those that an extended Internet 
fax system is expected to recognize its ability or non-ability to 
handle. 


Definitive descriptions of feature tags are indicated by reference to 


their registration according to the media feature registration 
procedure [1] (some of which are appended to this document). 
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NOTE: The presence of a feature tag in this list does 
not mean that an extended Internet fax system must have 
that capability; rather, it must recognize the feature 
tag and deal with it according to the capabilities that 
it does have. 


Further, an extended Internet fax system is not prevented 
from recognizing and offering additional feature tags. 
The list below is intended to provide a basic vocabulary 
that all extended Internet fax systems can use ina 
consistent fashion. 


If an unrecognized or unused feature tag is received, the 
feature set matching rule (described in [2]) operates so 


that tag is effectively ignored. 


3.1 Image size 


Feature tag name Legal values 
size-x <Rational> (>0) 
size-y <Rational> (>0) 


Reference: this document, Appendix A. 
These feature values indicate a rendered document size in inches. 


Where the actual size is measured in millimetres, a conversion 
factor of 10/254 may be applied to yield an exact inch-based value. 


3.2 Resolution 


Feature tag name Legal values 

dpi <Integer> (>0) 

dpi-xyratio <Rational> (>0) 

Reference: "Media Features for Display, Print, and Fax" [3], and this 


document appendix A. 


If ”dpi-xyratio” is present and not equal to 1 then the horizontal 
resolution (x-axis) is indicated by the 'dpi' feature value, and the 
vertical resolution (y-axis) is the value of ”dpi” divided by 'dpi- 
xyratio’. 
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For example, the basic Group 3 fax resolution of 200*100dpi might be 


indicated as: 


(& (dpi=200) 


(dpi-xyratio=200/100) ) 


When describing resolutions for an MRC format document, the complete 


set of usable resolutions is listed. 


However, there are some 


restrictions on their use: (a) 100dpi resolution can be used only 
with multi-level images, and (b) any multi-level image resolution is 
required to be an integral sub-multiple of the applicable mask 


resolution. 
3.3 Media type 


Feature tag name 


Legal values 
screen 
screen-paged 
stationery 
transparency 
envelope 
envelope-plain 
continuous 


Reference: "Media Features for Display, Print, and Fax" [3]. 


NOTE: Where the recipient indicates specific support for 
hard copy or soft copy media type, a sender of color 
image data may wish to adjust the color components (e.g. 
per the related rules of ITU recommendation T.42 [9]) to 
improve rendered image quality on that medium. 


3.4 Paper Size 


Feature tag name 


paper-size 


Legal values 


B4 
letter 
legal 


Reference: "Media Features for Display, Print, and Fax" [3]. 


Klyne & McIntyre 


Standards Track [Page 6] 


RFC 2879 Content Feature Schema for Internet Fax (V2) August 2000 


3.5 Color capability 


Feature tag name Legal values 


color Binary bi-level only) 


( 
Limited (a limited number of colors) 
Mapped (palette or otherwise mapped color) 
Grey (grey-scale only) 
Full (full continuous-tone color) 
Reference: "Media Features for Display, Print, and Fax" [3]. 


The intention here is to give a broad indication of color handling 
capabilities that might be used, for example, to select among a small 
number of available data resources. 


The value of this feature also gives an indication of the more 
detailed color handling features that might be applicable (see next 
section). 


"Binary" indicates blank-and-white, or other bi-level capability. No 
further qualifying feature tags are required. 


‘Limited’ indicates a small number of distinct fixed colors, such as 
might be provided by a highlight printer, pen plotter or limited 
color display. The ’color-levels’ tag should be used to indicate the 
number of distinct colors available. 


NOTE: No ability to indicate any specific or named color 


is implied by this option. Some devices might use 
different intensity levels rather than different hues for 
distinction. 


In the context of Internet fax, ‘limited’ is interpreted as one-bit- 
per-color-sample (RGB, CMY or CMYK), depending on the color space 
used. 


”Mapped' indicates that pixel color values are mapped in some 
specifiable way to a multi-component color space. The ”color-levels” 
tag may be used to indicate the number of distinct colors available; 
in its absence, sufficient levels to display a photographic image 
should be assumed. 


"Grey" indicates a continuous tone grey-scale capability. 


"Full" indicates full continuous tone color capability. 
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For ‘Mapped’, 'Grey' and ”Full” color, additional feature tags 
(section 3.6) may be used to further qualify the color reproduction. 


3.6 Color model 


Feature tag name Legal values 
color-levels <integer> >2) 
color-space Device-RGB device RGB) 


Device-CMY device CMY) 
Device-CMYK (device CMYK) 
CIELAB (LAB per T.42 [9]) 
(may be extended by further registrations) 

color-illuminant <token> (per ITU T.4 [13], E.6.7) 

D50 

D65 

D75 

SA 

SC 

F2 

F7 

F11 
CTnnnn (see below) 

CIELAB-L-depth <integer> (>0) 

CIELAB-a-depth H 

CIELAB-b-depth p 

CIELAB-L-min <integer> 

CIELAB-L-max " 

CIELAB-a-min n 

CIELAB-a-max L 

CIELAB-b-min " 

CIELAB-b-max y 


anana 


Reference: this document, appendix A. 


The general model for image handling (both color and non-color) is 
described here from a receiver's perspective; a similar model 
operates in the reverse direction for a scan/send perspective: 


raw bit pixel color physical 
stream -(A)-> values -(B)-> values -(C)-> rendition 


oad "raw bit stream" is a stream of coded bits 
(A) indicates image coding/decoding (MH,MR,MMR, JPEG, JBIG, etc.) 


= "pixel values" are a single numeric value per picture element 
that designates the color of that element. 
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(B) indicates pixel-to-color value mapping 


= "color values" have a separate numeric value for each color 
component (i.e. L*, a*, b* in the case of CIELAB indicated 
above.) 


(C) indicates how the color values are related to a physical 
color. This involves interpretation of the color value with 
respect to a color model (e.g. RGB, L*a*b*, CMY, CMYK) and a 
color space (which is typically recipient-dependent). 


= "physical rendition" is a color value physically realized on a 
display, printer or other device. 


There are many variables that can be applied at each stage of the 
processing of a color image, and any may be critical to meaningful 
handling of that image in some circumstances. In other circumstances 
many of the variables may be implied (to some level of approximation) 
in the application that uses them (e.g. color images published on a 
Web page). 


The color feature framework described here is intended to allow 
capability description at a range of granularity: feature tags which 
correspond to implied (or "don’t care" or "unknown") feature values 
may simply be omitted from a capability description. 


Grey scale and bi-level images are handled within this framework as a 
special case, having a 1-component color model. The following 
features are used for describing color capabilities: 


”color-levels” indicates the number of distinct values for each 
picture element, and applies to all but bi-level images. For bi- 
level images, a value of 2 is implied. 


”color-space' is used mainly with ”Mapped' and ’Full’, but could be 
used with other modes if the exact color or color model used is 
significant. Two kinds of color space can be distinguished: 
device-dependent and calibrated. Device dependent spaces are named 
here as 'Device-xxx', and are used to indicate a color space that is 
defined by the receiving device. Calibrated color spaces presume the 
existence of a rendering system that is calibrated with respect to an 
indicated definition, and is capable of processing the device- 
independent color information accordingly. 
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A color-handling receiver should indicate any appropriate device 
color space capability in addition to any calibrated color spaces 
that it may support. A calibrated color space should be used when 
precise color matching is required in the absence of specific 
knowledge of the receiving system. 


NOTE: In practice, although they appear to be separate 
concepts, the color model and color space cannot be 


separated. In the final analysis, a color model (RGB, 
CMY, etc.) must be defined with respect to some color 
space. 


”color-illuminant' indicates a CIE illuminant, using the same general 
form that is used for this purpose by Group 3 fax (as defined in ITU 
T.4 [13], section E.6.7). When the illuminant is specified by its 
color temperature, the token string ”CTnnnn' is used, where ”nnnn' is 
a decimal number that is the color temperature in Kelvins; e.g. 
CT7500 indicates an illuminant color temperature of 7500K. 


NOTE: ITU T.4 indicates a binary representation for color 
temperature values. 


In practice, much of the illuminant detail given here 
will probably be unused by Internet fax. The only value 
likely to be specified is 'D50', which is the default 
color illuminant for Group 3 fax. 


”CIELAB-L-depth', ”CIELAB-a-depth” and ’CIELAB-b-depth’ indicate the 
number of different values that are possible for the L*, a* and b* 
color components respectively, and are significant only when colors 
are represented in a CIELAB color space. These features would be 
used with palletized color, or with full color where each color 
component has a different number of possible values. 


Color depth values relate to the representation of colour values 
rather than the resolution of a scanning or rendering device. Thus, 
if 256 different L-component values can be represented then the 
assertion (CIELAB-L-depth<=256) is used, even if a receiving device 
can render only 100 distinct luminance values. (Color rendering 
resolution is not covered by this memo.) 


The ’CIELAB-x-min’ and 'CIELAB-x-max' values indicate a color gamut 
(i.e. a range of color values that are used or may be rendered). A 
gamut may be indicated in terms of the CIELAB color space even when 
colors are represented in some other space. 
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3.7 Image coding 


Feature tag name Legal values 
image-file- TIFF 
structure TIFF-limited 


TIFF-minimal 

TIFF-MRC 

TIFF-MRC-limited 

(may be extended by further registrations) 


image-coding MH 

MR 

MMR 

JBIG 

JPEG 

(may be extended by further registrations) 
image-coding- JBIG-T85 (bi-level, per ITU T.85) 
constraint JBIG-T43 (multi-level, per ITU T.43) 

JPEG-T4E (per ITU T.4, Annex E) 

(may be extended by further registrations) 
JBIG-stripe-size <Integer> 
image-interleave Stripe 

Plane 
color-subsampling ML seo slow (no color subsampling) 

vare pe (4:1:1 color subsampling) 


Reference: this document, appendix A. 


”image-file-structure” defines how the coded image data is wrapped 
and formatted. The following options are defined here: 


o 


‘TIFF’ indicates image data enclosed and tagged using TIFF 
structures described in Adobe's definition of TIFF [20]. 


”TIFF-limited” indicates image data structured using TIFF, but 
with the limitations on the placement of Image File Descriptors 
(IFDs) indicated in section 4.4.6 of RFC 2301 [7]. 


‘TIFF-minimal’ indicates a TIFF image format that meets the IFD 
placement, byte ordering and bit ordering requirements of the 
"minimal black and white mode" described in section 3.5 of RFC 
2301 [7], also known as TIFF-S. 


”TIFF-MRC' uses a TIFF image structure [20] augmented with a sub- 
IFD structure, described for the "Mixed Raster Content mode" in 
section 8.1.2 of RFC 2301 [7], also known as TIFF-M. This 
provides a file structure to contain composite images constructed 
using the MRC model described in T.44 [15] (see tag ”MRC-mode”). 
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o /TIFF-MRC-limited' is the same as /TIFF-MRC’, except that the 
primary IFD (i.e. top-level IFDs, as opposed to sub-IFDs) 
placement is constrained in the same way as ”TIFF-limited”. 


‘image-coding’ describes how raw image data is compressed and coded 
as a sequence of bits. These are generic tags that may apply to a 
range of file formats and usage environments. 


”image-coding-constraint” describes how the raw image data coding 
method is constrained to meet a particular operating environment. 
Options defined here are JBIG and JPEG coding constraints that apply 
in typical Group 3 fax environments. 


The 'JBIG-stripe-size' feature may be used with JBIG image coding, 
and indicates the number of scan lines in each stripe except the last 
in an image. The legal constraints are: 


(JBIG-stripe-size=128) 
(JBIG-stripe-size>=0) 


The latter being eguivalent to no restriction. 


NOTE: there are several image coding options here, and 
not all are reguired in all circumstances. 


Specification of the image-file-structure tag value alone 
is not normally sufficient to describe the capabilities 
of a recipient. A general rule is that sufficient detail 
should be provided to exclude any unsupported features. 


For extended Internet fax, image-file-structure and 
image-coding should always be specified, together with 
additional values described above as needed to clearly 
indicate which feature tag values are supported and which 
are not. (See also the examples in section 4.) 


3.8 MRC mode 
Feature tag name Legal values 


MRC-mode <Integer> (0..7) (per ITU T.44 [15]) 
MRC-max-stripe-size <Integer> 


Reference: this document, appendix A. 
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The ’MRC-mode’ feature is used to indicate the availability of MRC 
(mixed raster content) image format capability. A zero value 
indicates MRC is not available, a non-zero value indicates the 
maximum available MRC mode number. 


An MRC formatted document is actually a collection of several images, 
each of which is described by a separate feature collection. An 
MRC-capable receiver is presumed to be capable of accepting any 
combination of contained images that conform to both the MRC 
construction rules and the image-coding capabilities declared 
elsewhere. 


Within an MRC-formatted document, multi-level coders are used for 
foreground and background images (i.e. odd-numbered layers: 1, 3, 5, 
etc.) and bi-level coders are used for mask layers (i.e. even 
numbered layers 2, 4, 6, etc.). MRC format also imposes constraints 
on the resolutions that can be used. 


The ”MRC-max-stripe-size” feature may be used with MRC coding, and 
indicates the maximum number of scan lines in each MRC stripe. The 
legal constraints are: 


(MRC-max-stripe-size<=256) 
(MRC-max-stripe-size>=0) 


These values indicate upper bounds on the stripe size. The actual 
value may vary between stripes, and the actual size for each stripe 
is indicated in the image data. 


4. Examples 


The level of detail captured here reflects that used for capability 
identification in Group 3 facsimile. 


4.1 Simple mode Internet fax system 


This example describes the capabilities of a typical simple mode 
Internet fax system. Note that TIFF profile S is required to be 
supported by such a system. 
(& (image-file-structure=TIFF-minimal) 
MRC-mode=0) 
color=Binary) 
image-coding=MH) (MRC-mode=0) 
| (& (dpi=204) (dpi-xyratio=[204/98,204/196]) ) 
(& (dpi=200) (dpi-xyratio=[200/100,1]) ) ) 
(size-x<=2150/254) 
(paper-size=A4) 


( 
( 
( 
( 
( 
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(ua-media=stationery) ) 


4.2 High-end black-and-white Internet fax system 


(V2) 


August 2000 


This would include support for B/W JBIG and be equivalent to what is 
sometimes called "Super G3", except that Internet fax functionality 


would be added. 
(& (image-file-structure=TIFF) 

MRC-mode=0) 

color=Binary) 


( 
( 
( 
( 


(& (dpi=200) (dpi-xyratio=[200/100,1]) ) 
(& (dpi=300) (dpi-xyratio=1) ) ) 
(| (image-coding=[MH, MR, MMR] ) 

(& (image-coding=JBIG) 
(image-coding-constraint=JBIG-T85) 
(JBIG-stripe-size=128) ) ) 

(size-x<=2150/254) 
(paper-size=[letter,A4,B4]) ) 
(ua-media=stationery) ) 


4.3 Grey-scale Internet fax system 


| (& (dpi=204) (dpi-xyratio=[204/98,204/196]) 


) 


This is the previous example extended to handle grey scale multi- 
level images. In keeping with Group 3 fax, this example requires 


equal x- and y- resolutions for a multi-level image. 


(& (image-file-structure=TIFF) 
(MRC-mode=0) 
(| (& (color=Binary) 
(| (image-coding=[MH, MR, MMR] ) 
(& (image-coding=JBIG) 


JBIG-stripe-size=128) ) ) 
(| (8 


Ra RR 


(& (dpi=300) (dpi-xyratio=1) ) ) 
(color=Grey) 
(color-levels<=256) 
(color-space-CIELAB) 
(color-illuminant=D50) 
(CIELAB-L-min>=0) 
(CIELAB-L-max<=100) 
(| (& (image-coding=JPEG) 


image-coding-constraint=JPEG-T4E) 


( 
(4 (image-coding=JBIG) 
( 


image-coding-constraint=JBIG-T43) 
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image-coding-constraint=JBIG-T85) 


dpi=204) (dpi-xyratio=[204/98,204/196]) 
dpi=200) (dpi-xyratio=[200/100,1]) ) 


) 


) 
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(JBIG-stripe-size=128) 
(image-interleave=stripe) ) ) 
(dpi=[100,200,300]) (dpi-xyratio=1) ) ) 
(size-x<=2150/254) 
(paper-size=[letter,A4,B4]) ) 
(ua-media=stationery) ) 


4.4 Full-color Internet fax system (JPEG only) 
This adds 24-bit full-color to the previous example. 


(& (image-file-structure=TIFF) 

(MRC-mode=0) 

(| (& (color=Binary) 

(image-coding=[MH,MR,MMR]) 
(| (& (dpi=204) (dpi-xyratio=[204/98,204/196]) ) 

(& (dpi=200) (dpi-xyratio=[200/100,1]) ) 

(& (dpi=300) (dpi-xyratio=1) ) ) ) 
color=grey) 
image-coding=JPEG) 
image-coding-constraint=JPEG-T4E) 
color-levels<=256) 
color-space=CIELAB) 
color-illuminant=D50) 
CIELAB-L-min>=0) 
CIELAB-L-max<=100) 
dpi=[100,200,300]) (dpi-xyratio=1) ) 
color=full) 
image-coding=JPEG) 
image-coding-constraint=JPEG-T4E) 
color-subsampling=["1:1:1","4:1:1"]) 
color-levels<=16777216) 
color-space=CIELAB) 
color-illuminant=D50) 
CIELAB-L-min>=0) 
CIELAB-L-max<=100) 
CIELAB-a-min>=-85) 
CIELAB-a-max<=85) 
CIELAB-b-min>=-75) 
CIELAB-b-max<=125) 

(dpi=[100,200,300]) (dpi-xyratio=1) ) ) 

(size-x<=2150/254) 
(paper-size=[letter,A4,B4]) ) 
(ua-media=stationery) ) 


( 
( 
( 
( 
( 
( 
( 
( 
( 
( 
( 
( 
( 
( 
( 
( 
( 
( 
( 
( 
( 
( 
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4.5 Full-color Internet fax system (JPEG and JBIG) 


This adds limited CMY(K), RGB and 16-bit mapped color using JBIG 
coding to the previous example. 


(& (image-file-structure=TIFF) 
(MRC-mode=0) 
(| (& (color=Binary) 
(| (image-coding=[MH, MR, MMR] ) 

(& (image-coding=JBIG) 
image-coding-constraint=JBIG-T85) 
JBIG-stripe-size=128) ) ) 
dpi=204) (dpi-xyratio=[204/98,204/196]) ) 
dpi=200) (dpi-xyratio=[200/100,1]) ) 

(& (dpi=300) (dpi-xyratio=1) ) ) ) 

color=Limited) 

image-coding=JBIG) 

image-coding-constraint=JBIG-T43) 

JBIG-stripe-size=128) 

image-interleave=stripe) 

| (4 (color-space=[Device-RGB,Device-CMY]) 
(color-levels<=8) ) 

(4 (color-space=Device-CMYK) 

(color-levels<=16) ) ) 

dpi=[100,200,300]) (dpi-xyratio=1) ) 

color=Mapped) 

image-coding=JBIG) 

image-coding-constraint=JBIG-T43) 

JBIG-stripe-size=128) 

image-interleave=stripe) 

color-levels<=65536) 

color-space=CIELAB) 

color-illuminant=D50) 

CIELAB-L-min>=0) 

CIELAB-L-max<=100) 

CIELAB-a-min>=-85) 

CIELAB-a-max<=85) 

CIELAB-b-min>=-75) 

CIELAB-b-max<=125) 

dpi=[100,200,300]) (dpi-xyratio=1) ) 

color=grey) 

| (& (image-coding=JPEG) 

image-coding-constraint=JPEG-T4E) ) 

image-coding=JBIG) 

image-coding-constraint=JBIG-T43) 

JBIG-stripe-size=128) 
(image-interleave=stripe) ) ) 

(color-levels<=256) 


( 
( 
( 
( 
( 
( 
( 
( 
( 
( 
( 
( 
( 
( 
( 
( 
( 
( 
( 
( 
( 
( 
( 
( 
( 
( 
( 
( 


( 
(& ( 
( 
( 
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(color-space=CIELAB) 

(color-illuminant=D50) 

(CIELAB-L-min>=0) 

(CIELAB-L-max<=100) 

(dpi=[100,200,300]) (dpi-xyratio=1) ) 

(color=full) 

(| (& (image-coding=JPEG) 
(image-coding-constraint=JPEG-T4E) 
(color-subsampling=["1:1:1","4:1:1"]) ) 

(4 (image-coding=JBIG) 
(image-coding-constraint=JBIG-T43) 
(JBIG-stripe-size=128) 
(image-interleave=stripe) ) ) 

(color-levels<=16777216) 

(color-space=CIELAB) 

(color-illuminant=D50) 

(CIELAB-L-min>=0) 

(CIELAB-L-max<=100) 

(CIELAB-a-min>=-85) 

(CIELAB-a-max<=85) 

(CIELAB-b-min>=-75) 

(CIELAB-b-max<=125) 

(dpi=[100,200,300]) (dpi-xyratio=1) ) ) 

(size-x<=2150/254) 

(paper-size=[letter,A4,B4]) ) 

(ua-media=stationery) ) 


4.6 Full-color Internet fax system (MRC) 
This adds MRC image structures to the previous example. 


(& (image-file-structure=TIFF-MRC) 
(MRC-mode<=1) (MRC-max-stripe-size>=0) 
(| (& (color=binary) 
(| (image-coding=[MH, MR, MMR] ) 

(& (image-coding=JBIG) 
(image-coding-constraint=JBIG-T85) 
(JBIG-stripe-size=128) ) ) 

(& (dpi=204) (dpi-xyratio=[204/98,204/196]) ) 

(& (dpi=200) (dpi-xyratio=[200/100,1]) ) 

(4 (dpi=[300,400]) (dpi-xyratio=1) ) ) ) 

lor=limited) 

(4 (color-space=[Device-RGB,Device-CMY]) 
(color-levels<=8) ) ) 

(| (& (color-space=Device-CMYK) 

(color-levels<=16) ) ) 
(image-coding=JBIG) 
(image-coding-constraint=JBIG-T43) 
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JBIG-stripe-size=128) 

image-interleave=stripe) 

dpi=[100,200,300,400]) (dpi-xyratio=1) ) 

color=mapped) 

color-levels<=65536) 

image-coding=JBIG) 

image-coding-constraint=JBIG-T43) 

JBIG-stripe-size=128) 

image-interleave=stripe) 

color-space=CIELAB) 

CIELAB-L-min>=0) 

CIELAB-L-max<=100) 

CIELAB-a-min>=-85) 

CIELAB-a-max<=85) 

CIELAB-b-min>=-75) 

CIELAB-b-max<=125) ) ) 

color-illuminant=D50) 

dpi=[100,200,300,400]) (dpi-xyratio=1) ) 

color=grey) 

| (& (image-coding=JPEG) 

image-coding-constraint=JPEG-T4E) ) 

image-coding=JBIG) 

image-coding-constraint=JBIG-T43) 

JBIG-stripe-size=128) 
(image-interleave=stripe) ) ) 

color-space=CIELAB) 

color-levels<=256) 

color-illuminant=D50) 

CIELAB-L-min>=0) 

CIELAB-L-max<=100) 

dpi=[100,200,300,400]) (dpi-xyratio=1) ) 

color=full) 

| (& (image-coding=JPEG) 
(image-coding-constraint=JPEG-T4E) 
(color-subsampling=["1:1:1","4:1:1"]) ) 

(4 (image-coding=JBIG) 

( 

( 


( 
( 
( 
( 
( 
( 
( 
( 
( 
( 
( 
( 
( 
( 
( 
( 
( 
( 
( 
( 


( 
(& ( 
( 
( 


( 
( 
( 
( 
( 
( 
( 
( 


image-coding-constraint=JBIG-T43) 

JBIG-stripe-size=128) 

(image-interleave=stripe) ) ) 
(color-levels<=16777216) 
(color-space=CIELAB) 
(color-illuminant=D50) 
(CIELAB-L-min>=0) 
(CIELAB-L-max<=100) 
(CIELAB-a-min>=-85) 
(CIELAB-a-max<=85) 
(CIELAB-b-min>=-75) 
(CIELAB-b-max<=125) 
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(dpi=[100,200,300,400]) (dpi-xyratio=1) ) ) 
(size-x<=2550/254) 
(Paper-size=[Letter,A4,B4]) 
(ua-media=stationery) ) 


4.7 Sender and receiver feature matching 


This example considers sending a document to an enhanced black-and- 
white fax system with the following receiver capabilities: 


(& (| (& (dpi=200) (dpi-xyatio=200/100) ) 
(& (dpi=200) (dpi-xyratio=1) ) 
(& (dpi=300) (dpi-xyratio=1) ) 
(& (dpi=400) (dpi-xyratio=1) ) ) 
(color=Binary) 
(| (& (paper-size=A4) (ua-media=[stationery,transparency]) ) 
(& (paper-size=B4) (ua-media=continuous) ) ) 


(image-coding=[MH,MR,JBIG]) ) 


Turning to the document itself, assume it is available to the sender 
in three possible formats, A4 high resolution, B4 low resolution and 
A4 high resolution color, described by: 

(& (dpi=300) (dpi-xyratio=1) 
(color=Binary) 
(paper-size=A4) 
(image-coding=[MMR, JBIG]) ) 
(dpi=200) (dpi-xyratio=200/100) 
(color=Binary) 

(paper-size=B4) 
(image-coding=[MH,MR]) ) 
(dpi=300) (dpi-xyratio=1) 

(color=Mapped) (color-levels<=256) 

(paper-size=A4) 

(image-coding=JPEG) ) 

These three image formats can be combined into a composite capability 
statement by a logical-OR operation (to describe format-l OR format-2 
OR format-3): 


(| (& (dpi=300) (dpi-xyratio=1) 
(color=Binary) 
(paper-size=A4) 
(image-coding=[MMR,JBIG]) ) 
(& (dpi=200) (dpi-xyratio=200/100) 
( 


color=Binary) 
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(paper-size=B4) 

(image-coding=[MH,MR]) ) 

(dpi=300) (dpi-xyratio=1) 

(color=Mapped) (color-levels=42) 

(paper-size=A4) 

(image-coding=JPEG) ) ) 

This could be simplified, but there is little gain in doing so at 
this point. 


The composite document description can be matched with the receiver 
capability description, according to the rules in [2], to yield the 


result: 
(| (& (dpi=300) (dpi-xyratio=1) 
color=Binary) 
paper-size=A4) 
ua-media=[stationery,transparency]) 
image-coding=JBIG) ) 
(& (dpi=200) (dpi-xyratio=200/100) 


( 
( 
( 
( 
( 
( 
(color=Binary) 
(paper-size=B4) 
(ua-media=continuous) 
(image-coding=[MH,MR]) ) ) 


Points to note about the feature matching process: 


o The color document option is eliminated because the receiver 
cannot handle either color (indicated by ’ (color=Mapped)’) or 
JPEG coding (indicated by ’ (image-coding=JPEG)’). 


o The high resolution version of the document with ’ (dpi=300)’ must 
be send using ’ (image-coding=JBIG)’ because this is the only 
available coding of the image data that the receiver can use for 
high resolution documents. (The available 300dpi document 
codings here are MMR and JBIG, and the receiver capabilities are 
MH, MR and JBIG.) 


o The low-resolution version of the document can be sent with 
either MH or MR coding as the receiver can deal with either of 
these for low resolution documents. 


o The high resolution variant of the document is available only for 
A4, so that is the paper-size used in that case. Similarly the 
low resolution version is sent for B4 paper. 


o Even though the sender may not understand the ’ua-media’ feature 
tag, and does not mention it, the matching rules preserve the 
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constraint that the B4 document is rendered with 
” (ua-media=continuous)”, and the A4 document may be rendered with 
” (ua-media=[stationery,transparency]l)”. 


Finally, note that when matching an MRC document description, the 
description of each component sub-image must match the capabilities 
of the intended receiver. 


5. IANA Considerations 


Appendix A of this document repeats the descriptions of feature tags 
introduced by RFC 2531 [22], with some small revisions. These have 
been registered in the "IETF tree", according to the procedure 
described in section 3.1.1 of "Media Feature Tag Registration 
Procedure" [1] (i.e. these feature tags are subject to the "IETF 
Consensus" policies described in RFC 2434 [21]). 


Appendix section A.5 introduces one new feature tag (color- 
illuminant) to be registered according to the same procedure. An 
ASN.1 identifier should be assigned for this new tag and replaced in 
the body of the registration. 


6. Security Considerations 
The points raised below are in addition to the general security 


considerations for extended Internet fax [5], and others discussed in 
[2,8,11,12,13] 


6.1 Capability descriptions and mechanisms 


Negotiation mechanisms reveal information about one party to other 


parties. This may raise privacy concerns, and may allow a malicious 
party to make better guesses about the presence of specific security 
holes. 


Most of these concerns pertain to capability information getting into 
the hands of someone who may abuse it. This document specifies 
capabilities that help a sender to determine what image 
characteristics can be processed by the recipient, not mechanisms for 
their publication. Implementers and users should take care that the 
mechanisms employed ensure that capabilities are revealed only to 
appropriate persons, systems and agents. 


6.2 Specific threats 
1. Unsolicited bulk mail: if it is known that a recipient can 


process certain types of images, they may be targeted by bulk 
mailers that want to send such images. 
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Appendix A: Feature registrations 
A.1 Image size 
- Media Feature tag name(s): 


size-x 
size-y 


- ASN.1 identifiers associated with these feature tags: 
size-x: TSG LGT 
size-y: 1.3.6.1.8.1.8 
- Summary of the media features indicated: 
These feature tags indicate the size of a displayed, printed 
or otherwise rendered document image; they indicate 


horizontal (size-x) and vertical (size-y) dimensions. 


The unit of measure is inches (to be consistent with the 
measure of resolution defined by the feature tag ’dpi’). 


Where the actual size is available in millimetres, a 
conversion factor of 10/254 may be applied to yield an exact 
inch-based value. 

- Values appropriate for use with these feature tags: 


Rational (>0) 


- The feature tag is intended primarily for use in the following 
applications, protocols, services, or negotiation mechanisms: 


Print and display applications where different media choices 
will be made depending on the size of the recipient device. 


- Examples of typical use: 


This example describes the maximum scanned image width and 
height for Group 3 fax: 215x297 mm (8.46x11.69 inches): 


(size-x<=2150/254) 
(size-y<=2970/254) 
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- Related standards or documents: 


The memo "Media Features for Display, Print, and Fax" [3] 
describes features (pix-x, pix-y) for measuring document size 
in pixels. 


Fax applications should declare physical dimensions using the 
features defined here. 


- Considerations particular to use in individual applications, 
protocols, services, or negotiation mechanisms: 


Where no physical size is known or available, but a pixel size 
is known, a notional size should be declared based upon known 
pixel dimensions and a notional resolution of (say) 100dpi 


For example, to describe a 640x480 pixel display: 

(& (size-x<=640/100) (size-y<=480/100) (dpi=100) ) 
The notional 100dpi resolution is used as it represents a 
fairly typical resolution for a pixel-limited display. 
Reducing the rational numbers to canonical form gives the 
following equivalent expression: 

(& (size-x<=32/5) (size-y<=24/5) (dpi=100) ) 

- Interoperability considerations: 

For interoperability with other (non-fax) applications that 
use only pixel-based measurements, pixel dimensions (pix-x, 


pix-y) may be declared in addition to physical measurements. 


- Related feature tags: 


pix-x [3] 
pix-y [3] 
dpi [3] 
dpi-xyratio [this document] 


- Intended usage: 


Common 
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- Author/Change controller: 

IETF 
A.2 Resolution aspect ratio 

- Media Feature tag name(s): 
dpi-xyratio 

- ASN.1 identifier associated with this feature tag: 
1.3.6.1 68.1.9 

- Summary of the media features indicated: 
This feature is used to indicate differential horizontal and 
vertical resolution capability. In the absence of this 
feature, horizontal and vertical resolutions are presumed to 
be the same. 
When this feature tag is specified, any declared resolution 
(dpi) is presumed to apply to the horizontal axis, and the 
vertical resolution is obtained by dividing that declared 


resolution by the resolution ratio. 


The value of this feature is a pure number, since it 
represents the ratio of two resolution values. 


- Values appropriate for use with this feature tag: 
Rational (>0) 


- The feature tag is intended primarily for use in the following 
applications, protocols, services, or negotiation mechanisms: 


Internet fax, and other print or display applications that 
must handle differential horizontal and vertical resolution 
values. 


- Examples of typical use: 


The following example describes a fax resolution of 204 dpi 
horizontally by 391 dpi vertically: 


(& (dpi=204) (dpi-xyratio=204/391) ) 
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- Related standards or documents: 


The memo "Media Features for Display, Print, and Fax" [3] 
describes a feature (dpi) for measuring document resolution. 


- Interoperability considerations: 
When interoperating with an application that does not 
recognize the differential resolution feature, resolution 
matching may be performed on the basis of the horizontal 


resolution only, so aspect ratio information may be lost. 


- Related feature tags: 


dpi [3] 
size-x [this document] 
size-y [this document] 


- Intended usage: 
Internet fax 

- Author/Change controller: 
IETF 

A.3 Color levels 

- Media Feature tag name(s): 
color-levels 

- ASN.1 identifier associated with this feature tag: 
1936.01 SLO 

- Summary of the media features indicated: 


This feature tag is used to indicate a number of different 
image data pixel color values. 


When mapped (palletized) color is used, this is generally 
different from the number of different colors that can be 


represented through the color mapping function. 


This feature tag is used in conjunction with a ’color’ feature 
having a value other than "Binary". 
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- Values appropriate for use with this feature tag: 
Integer (>=2) 


- The feature tag is intended primarily for use in the following 
applications, protocols, services, or negotiation mechanisms: 


Color image printing or display applications where the data 
resource used may depend upon color handling capabilities of 


the recipient. 


- Examples of typical use: 


To describe recipient capabilities: 

(& (color=limited) (color-levels<=6) ) 

(& (color=grey) (color-levels<=64) ) 

(& (color=mapped) (color-levels<=240) ) 

(& (color=full) (color-levels<=16777216) ) 
o describe capabilities used by a document: 


T 
( (color=limited) (color-levels=4) ) 

( (color=grey) (color-levels=48) ) 

(4 (color=mapped) (color-levels=100) ) 

( (color=full) (color-levels=32768) ) 


- Related standards or documents: 


The memo "Media Features for Display, Print, and Fax" [3] 
describes a feature (color) for indicating basic color 
capabilities. 


- Interoperability considerations: 


The actual number of color values used by a document does not, 
in general, exactly match the number that can be handled by a 
recipient. To achieve a feature match, at least one must be 
declared as an inequality (i.e. not both as equalities). 


It is recommended that a recipient declares the number of 
color values that it can handle as an inequality (<=), anda 
data resource declares the number of colors that it uses with 
an equality, as shown in the examples above. 
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- Security considerations: 


- Privacy concerns, related to 
Where feature matching is 
to the physical abilities 
feature tag might give an 
abilities. 


- Related feature tags: 


color [3] 


color-space 
- Intended usage: 


Internet fax 


for Internet Fax (V2) August 2000 


exposure of personal information: 
used to select content applicable 
of a user, unusual values for this 
indication of a user’s restricted 


[this document] 


Color image scanning/rendering applications 


- Author/Change controller: 
IETF 
A.4 Color space 
- Media Feature tag name(s): 


color-space 


- ASN.1 identifier associated with this feature tag: 


LS GrAL gL EL 


- Summary of the media features indicated: 


This feature indicates a color space. 


A color space value provides 


o the color model used to represent a color value, 


two types of information: 
including 


the number of color components 
o a mapping between color values and their physical 


realizations 


Device color space values are defined for applications where 


the general color representation used is significant, 
exact color rendering is left to the device used. 


but 
Device 


color spaces defined here have values of the form ’Device- 


xxx". 
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Calibrated color space values are provided for use with a 
rendering system that is calibrated with respect to some 
indicated definition, and capable of processing device- 
independent color information accordingly. 


- Values appropriate for use with this feature tag: 


Token 

Device color Device-RGB (device dependent RGB) 

spaces: Device-CMY (device dependent CMY) 
Device-CMYK (device dependent CMYK) 

Calibrated color CIELAB (per T.42 [9]) 

space: 


(may be extended by further registrations) 
”Color-space=CIELAB' indicates the CIE L*a*b* colour space, 
using CIED50 illuminant and its perfectly diffuse reflecting 
white point (per T.42 [9]). 


- The feature tag is intended primarily for use in the following 
applications, protocols, services, or negotiation mechanisms: 


Color image printing and display applications where the data 
resource used may depend upon color handling capabilities of 


the recipient. 


Scanning applications where the data transferred may depend 
upon the image generation capabilities of the originator. 


- Examples of typical use: 
To describe rendering or scanning capabilities: 
(color-space=[Device-RGB, CIELAB] ) 


To describe capabilities assumed by a document for which 
approximate color reproduction is required: 


(color-space=Device-RGB) 


To describe capabilities assumed by a document for which exact 
color reproduction is required: 


(color-space=CIELAB) 
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- Related standards or documents: 

CIELAB color space is defined in [19] 

CIELAB use for fax is described in ITU T.42 [9] 
- Interoperability considerations: 


A color-handling receiver should indicate any appropriate 
device color space capability, in addition to any calibrated 
color spaces that it may support. 


Calibrated color spaces are intended to be used when precise 
color matching is required; otherwise, if applicable, a 
device color space (color-space=Device-xxx) should be 
indicated. 


Documents for which exact color matching is not important 
should indicate a device color space capability, if 
applicable. 


These principles allow sender/receiver feature matching to be 
achieved when exact color matching is not required. 


- Security considerations: 


- Privacy concerns, related to exposure of personal information: 
Where feature matching is used to select content applicable 
to the physical abilities of a user, unusual values for this 
feature tag might give an indication of a user’s restricted 
abilities. 


- Denial of service concerns related to consequences of 
specifying incorrect values: 
Failure to indicate a generic color space capability for a 
device may lead to failure to match color space for an 
application or document that does not require an exact color 
match. 


- Related feature tags: 


color [3] 
- Related media types or data formats: 


TIFF-FX [7] 
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- Intended usage: 


Internet fax 
Color image scanning/rendering applications 


- Author/Change controller: 

IETF 
A.5 CIELAB color illuminant 

- Media Feature tag name(s): 
color-illuminant 

- ASN.1 identifier associated with this feature tag: 
L 6 Ook. 29 

- Summary of the media features indicated: 
This feature indicates a color illuminant. This has the 
effect of modifying the color space calibration to reflect the 


use of different sources of illumination. 


A color-illuminant value would normally be used only with a 
calibrated color space. 


- Values appropriate for use with this feature tag: 
Token 


CIELAB illuminant D50 
values: D65 
D75 
SA 
SC 
F2 
F7 
F11 


Defined by color CTnnnn where ”nnnn' is a decimal 
temperature: representation of the illuminant 


color temperature in Kelvins. 


(may be extended by further registrations) 
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NOTE: The default color illuminant for Group 3 fax is D50. 


- The feature tag is intended primarily for use in the following 
applications, protocols, services, or negotiation mechanisms: 


Color image printing and display applications where the data 
resource used may depend upon detailed color handling 


capabilities of the recipient. 


Scanning applications where the data transferred may depend 
upon the image generation capabilities of the originator. 


- Examples of typical use: 


To describe rendering or scanning capabilities, or to describe 
capabilities assumed by a document for which exact color 
handling capabilities are required: 


(& (color-space=CIELAB) (color-illuminant=D50) ) 
- Related standards or documents: 


CIELAB color illuminant representations are described in ITU 
T.4 [13], Annex E.6.7. 


- Interoperability considerations: 


A color-handling receiver that supports a calibrated color 
space should indicate any constraint on the illuminants it can 
handle. 


In the absence of a color-illuminant constraint, a receiver is 
presumed to accept and deal with any specified illuminant 
value. 


- Related feature tags: 


color [3] 
color-space [this document] 


- Related media types or data formats: 
TIFF-FX [7] 
- Intended usage: 


Internet fax 
Color image scanning/rendering applications 
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- Author/Change controller: 
IETF 
A.6 CIELAB color depth 
- Media Feature tag name(s): 
CIELAB-L-depth 
CIELAB-a-depth 


CIELAB-b-depth 


- ASN.1 identifiers associated with these feature tags: 


CIELAB-L-depth: T3868. 8: 1.12 
CIELAB-a-depth: 14356, 12801513 
CIELAB-b-depth: 1.3.6 312.81 514 


- Summary of the media features indicated: 


These feature tags indicate a color depth capability; i. 
the level of detail to which an individual CIELAB color 
component can be specified. They define the number of 


distinct values possible for each of the color components L*, 


a* and b*. 


Typically, this feature would be used with ’color=mapped’ , 
possibly ’color=grey’ or ”color=full", to indicate the number 


of distinct colors that can be represented. 


NOTE: this feature tag describes the number of values that 


can be represented for a color component, and does not 


necessarily indicate the number of distinct values that can 


be rendered or resolved by a system. 
- Values appropriate for use with these feature tags: 
Integer (>0) 
- These feature tags are intended primarily for use in the 


following applications, protocols, services, or negotiation 
mechanisms: 


Color image printing and display applications where the data 
resource used may depend upon color handling capabilities of 


the recipient. 
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Scanning applications where the data transferred may depend 
upon the image generation capabilities of the originator. 

- Examples of typical use: 


To describe rendering or scanning capabilities: 


(& (color=mapped) (color-levels<=240) 
CIELAB-L-depth<=128) 
CIELAB-a-depth<=128) 

(& (color=full) (color-levels<=16777216) 


( 
( 
( 
(CIELAB-b-depth<=128) ) 
( 
(CIELAB-L-depth<=256) 

(CIELAB-a-depth<=128) 

(CIELAB-b-depth<=128) ) 


To describe capabilities assumed by a document: 


(& (color=mapped) (color-levels=200) 
CIELAB-L-depth=32) 
CIELAB-a-depth=32) 
CIELAB-b-depth=32) ) 

(& (color=full) (color-levels=32768) 


( 
( 
( 
( 
( 
(CIELAB-L-depth=128) 
(CIELAB-a-depth=32) 

(CIELAB-b-depth=32) ) 


- Related standards or documents: 


The memo "Media Features for Display, Print, and Fax" [3] 
defines a feature (color) for indicating basic color 
capabilities. 


CIELAB color space is defined in [19] 
CIELAB use for fax is described in ITU T.42 [9] 


- Related feature tags: 


color [3] 
color-levels [this document ] 
color-space [this document] 


- Intended usage: 


Internet fax 
Color image scanning/rendering applications 
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IETF 


Author/Change controller: 


A.7 CIELAB color gamut 


CIELAB-L-min 
CIELAB-L-max 
CIELAB-a-min 
CIELAB-a-max 
CIELAB-b-min 
CIELAB-b-max 


CIELAB-L-min: 
CIELAB-L-max: 
CIELAB-a-min: 
CIELAB-a-max: 
CIELAB-b-min: 
CIELAB-b-max: 


Summary of the media features 


Media Feature tag name(s): 


1.3.6.1.8.1.15 
1.3.6.1.8.1.16 
143464 14811 
1.3.6.1.8.1.18 
1.3.6.1.8.1.19 
1.3.6.1.8.1.20 
indicated: 


Fax 


(V2) 


ASN.1 identifiers associated with these feature tags: 


August 2000 


These feature indicate a supported range of color values, by 
indicating minimum and maximum values used for each color 


component in 


a CIELAB color space. 


”CIELAB-L-min'” and ”CIELAB-L-max' are the minimum and maximum 
values of the L* component. 


”CIELAB-a-min'” and ”CIELAB-a-max' are the minimum and maximum 
values of the a* component. 


”CIELAB-b-min'” and ”CIELAB-b-max' are the minimum and maximum 
values of the b* component. 


NOTE: 
numbers, 
limited c 


Rational 


Klyne & McIntyre 


color component values are assumed to be rational 


so a limited gamut does not necessarily indicate 


olor resolution. 


Standards Track 


Values appropriate for use with this feature tag: 
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- The feature tag is intended primarily for use in the following 
applications, protocols, services, or negotiation mechanisms: 


Color image printing and display applications where the data 
resource used may depend upon detailed color handling 
capabilities of the recipient. 


Scanning applications where the data transferred may depend 
upon the detailed color image generation capabilities of the 
originator. 

- Examples of typical use: 

To describe rendering or scanning capabilities: 

(& (CIELAB-L-min>=0) 
(CIELAB-L-max<=100) 
(CIELAB-a-min>=-75) 
(CIELAB-a-max<=+75) 
(CIELAB-b-min>=-85) 
(CIELAB-b-max<=+85) ) 

To describe capabilities reguired by a document: 
(4 (CIELAB-L-min=20) 
CIELAB-L-max=80) 
CIELAB-a-min=-35 
CIELAB-a-max=+55 
CIELAB-b-min=-45 


( 
( 
( 
( 
( 
(CIELAB-b-max=+65 


) 
) 
) 
) ) 
- Related standards or documents: 
CIELAB color space is defined in [19] 
CIELAB use for fax is described in ITU T.42 [9] 
- Interoperability considerations: 
When describing a recipient’s capabilities, the minimum and 
maximum color component values that can be rendered should be 
indicated by inequalities as shown in the examples above. 
When describing a document, the actual minimum and maximum 


color component values used should be indicated, as shown 
above. 
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- Security considerations: 

- Privacy concerns, related to exposure of personal information: 
Where feature matching is used to select content applicable 
to the physical abilities of a user, unusual values for this 
feature tag might give an indication of a user’s restricted 
abilities. 


- Related feature tags: 


color [3] 
color-space [this document ] 


- Related media types or data formats: 
TIFF-FX [7] 
- Intended usage: 


Internet fax 
Color image scanning/rendering applications 


- Author/Change controller: 

IETF 
A.8 Image file structure 

- Media Feature tag name(s): 
image-file-structure 

- ASN.1 identifier associated with this feature tag: 
143+46.1 81.21 

- Summary of the media features indicated: 


This feature indicates a file structure used for transfer and 
presentation of image data. 


It does not indicate image data coding: that is described by 
separate feature tags (image-coding, etc.). 
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- Values appropriate for use with this feature tag: 


Token 

Image file TIFF 
structure TIFF-limited 
options: TIFF-minimal 


TIFF-MRC 
TIFF-MRC-limited 


(may be extended by further registrations, 
to cover non-TIFF image file structures) 


- The feature tag is intended primarily for use in the following 
applications, protocols, services, or negotiation mechanisms: 


Internet fax, and other print or display applications that 
transfer image data. 


- Examples of typical use: 
See Appendix B of this memo. 


- Considerations particular to use in individual applications, 
protocols, services, or negotiation mechanisms: 


This tag is intended to provide information about an image 
file structure. Information about image data coding is 
provided by other tags. 


The following tag values are defined here: 


o ‘TIFF’ indicates image data enclosed and tagged using TIFF 
structures described in Adobe’s definition of TIFF [20]. 


o /TIFF-limited' indicates image data structured using TIFF, 
but with limitations on the placement of Image File 
Descriptors (IFDs) within the file, which are indicated in 
section 4.4.6 of RFC 2301 [7]. 


o /TIFF-minimal' indicates a TIFF image format that meets the 
IFD placement, byte ordering and bit ordering requirements 
of the "minimal black and white mode" described in section 
3.5 of RFC 2301 [7], also known as TIFF-S. 
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o /TIFF-MRC' uses a TIFF image structure [20] augmented with a 
sub-IFD structure, described for the "Mixed Raster Content 
mode" in section 8.1.2 of RFC 2301 [7], also known as TIFF-M 
(see also tag ’MRC-mode’). 


o /TIFF-MRC-limited' is the same as ”TIFF-MRC', except that 
the IFD placement is constrained as for /TIFF-limited’. 


Registration of additional image file structure tags should 
focus similarly on image file structure issues, not raw image 
data compression and coding. As a guide, an image file 
structure may contain image data coded in a variety of ways, 
and carries information to describe that coding separately 
from MIME content-type labelling, etc. 


- Related feature tags: 


image-coding [this document] 
MRC-mode [this document] 


- Related media types or data formats: 


TIFF-FX [7] 
TIFF V6.0 (Adobe) [20] 


- Intended usage: 


Internet fax 
Image scanning/rendering applications 


- Author/Change controller: 

IETF 
A.9 Image data coding 

- Media Feature tag name(s): 
image-coding 

- ASN.1 identifier associated with this feature tag: 
Tige 6. 1851/22 

- Summary of the media features indicated: 


This feature tag indicates a form of image data compression 
and coding used. 
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It identifies a generic image coding technique used, without 
regard to any specific profiling of that technique that may be 
applied. Values for this feature are generally applicable 
across a wide range of image transfer applications. 


This information is distinct from the image file structure and 
MRC information conveyed by the ’image-file-structure’ tags. 


- Values appropriate for use with this feature tag: 
Token MH 
MR 
MMR 
JBIG 
JPEG 


(may be extended by further registrations) 


- The feature tag is intended primarily for use in the following 
applications, protocols, services, or negotiation mechanisms: 


Internet fax, and other applications that transfer image data. 
- Examples of typical use: 
See Appendix B of this memo. 


- Related standards or documents: 


MH, MR: ITU T.4 [13] 
MMR: LTU 1.6 [14] 
JPEG: ITU T.81 [16] 
JBIG: ITU T.82 [17] 


- Interoperability considerations: 


To establish the correct conditions for interoperability 
between systems, capabilities to handle the generic image 
coding technique and the specific image coding constraints 
must be established. 


- Related feature tags: 


image-coding-constraint [this document] 
JBIG-stripe-size [this document] 
image-interleave [this document] 
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- Related media types or data formats: 
TIFF-FX [7] 
- Intended usage: 


Internet fax 
Image scanning/rendering applications 


- Author/Change controller: 

IETF 
A.10 Image coding constraint 

- Media Feature tag name(s): 
image-coding-constraint 

- ASN.1 identifier associated with these feature tags: 
LJI3.L60L80123 

- Summary of the media features indicated: 


This feature tag qualifies the ’image-coding’ feature with a 
specific profile or usage constraints. 


Values for this feature are generally specific to some given 
value of ’image-coding’ and also to some restricted 


application or class of applications. 


- Values appropriate for use with this feature tag: 


Token JBIG-T85 (bi-level, per ITU T.85) 
JBIG-T43 (multi-level, per ITU T.43) 
JPEG-T4E (per ITU T.4, Annex E) 


(may be extended by further registrations) 


- The feature tag is intended primarily for use in the following 
applications, protocols, services, or negotiation mechanisms: 


Internet fax, and other applications that transfer image data. 


The specific values for this feature indicated above are 
intended for use with Internet fax. 
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Examples of typical use: 
See Appendix B of this memo. 


- Related standards or documents: 


JBIG-T85: ITU T.85 [18] 
JBIG-T43: ITU T.43 [10] 
JPEG-T4E: ITU T.4 Annex E [13] 


- Interoperability considerations: 


To establish the correct conditions for interoperability 
between systems, capabilities to handle the generic image 
coding technique and the specific image coding constraints 
must be established. 


- Related feature tags: 


image-coding [this document] 
JBIG-stripe-size [this document] 
image-interleave [this document] 


- Related media types or data formats: 
TIFF-FX [7] 
- Intended usage: 


Internet fax 
Color image scanning/rendering applications 


- Author/Change controller: 
IETF 
A.11 JBIG stripe size 
- Media Feature tag name(s): 
JBIG-stripe-size 
- ASN.1 identifier associated with these feature tags: 


1.3.6.1.8:1:24 
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- Summary of the media features indicated: 
This feature is a specific usage constraint that is applied to 
JBIG image coding (image-coding=JBIG), and indicates the 
allowable size for each stripe of an image, except the last. 
A stripe of a JBIG image is a delimited horizontal band of 
compressed image data that can be decompressed separately from 
the surrounding data. 

- Values appropriate for use with this feature tag: 


Integer (>0) 


- The feature tag is intended primarily for use in the following 
applications, protocols, services, or negotiation mechanisms: 


Internet fax, and other applications that transfer image data. 
- Examples of typical use: 


(JBIG-stripe-size=128) 
(JBIG-stripe-size>0) 


- Related standards or documents: 


JBIG: ITU. 1482: [17] 
JBIG-T85: ITU T.85 [18] 
JBIG-T43: ITU 1.43: [10] 


- Considerations particular to use in individual applications, 
protocols, services, or negotiation mechanisms: 


In the case of Internet fax, the specific constraints allowed 
for a receiver are those given as examples above. 


Specifying a stripe size that is not limited (JBIG-stripe- 
size>0) means that an entire page of image data is encoded as 
a single unit. This may place considerable demands on the 
memory of a receiving system, as the entire stripe needs to be 
buffered in memory. 


- Interoperability considerations: 
To establish the correct conditions for interoperability 
between systems, capabilities to handle the generic image 


coding technique and the specific image coding constraints 
must be established. 
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- Related feature tags: 


image-coding [this document] 
image-coding-constraint [this document] 
image-interleave [this document] 


- Related media types or data formats: 
TIFF-FX [7] 
- Intended usage: 


Internet fax 
Color image scanning/rendering applications 


- Author/Change controller: 

IETF 
A.12 Image interleave 

- Media Feature tag name(s): 
image-interleave 

- ASN.1 identifier associated with this feature tag: 
L.3J6.L 821.25 

- Summary of the media features indicated: 
This feature indicates an image interleave capability. 
It may be used with JBIG images (image-coding=JBIG) to 
indicate color plane interleaving of either stripes or entire 
image planes. 

- Values appropriate for use with this feature tag: 


Token Stripe 
Plane 


- The feature tag is intended primarily for use in the following 
applications, protocols, services, or negotiation mechanisms: 


Internet fax, and other applications that transfer image data. 
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Examples of typical use: 


(image-interleave=stripe) 
(image-interleave=[stripe,plane]) 


- Considerations particular to use in individual applications, 
protocols, services, or negotiation mechanisms: 


Specifying a plane interleave means that an entire page of 
image data must be buffered in order to generate or render the 
image. This may place considerable demands on the memory of a 
sending or receiving system. 


- Related feature tags: 


image-coding [this document] 
JBIG-stripe-size [this document] 


- Related media types or data formats: 
TIFF-FX L] 
- Intended usage: 


Internet fax 
Color image scanning/rendering applications 


- Author/Change controller: 

IETF 
A.13 Color subsampling 

- Media Feature tag name(s): 
color-subsampling 

- ASN.1 identifier associated with this feature tag: 
13464 14841426 

- Summary of the media features indicated: 


This feature tag indicates whether color information may be 
subsampled with respect to luminance data. 
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It is used with continuous color images (color=full), color 
spaces that use separate luminance and color components 
(e.g. color-space=LAB), and image file structures that support 
color subsampling. 

- Values appropriate for use with this feature tag: 


String sl et Easel Ey 
This value indicates a full set of color 
component samples for each luminance 
component sample. 
"45114 
This value indicates one set of color component 
samples for each 4 luminance samples. 
(may be extended by further registrations) 


- The feature tag is intended primarily for use in the following 
applications, protocols, services, or negotiation mechanisms: 


Color image printing and display applications where the data 
resource used may depend upon color handling capabilities of 


the recipient. 


Scanning applications where the data transferred may depend 
upon the image generation capabilities of the originator. 


- Examples of typical use: 


(4 (color=full) (color-space=[LAB, CIELAB] ) 
(color-subsampling=["1:1:1","4:1:1"]) ) 


- Related feature tags: 
color [3] 
color-space [this document ] 
image-file-structure [this document] 
- Related media types or data formats: 
TIFF-FX [7] 


- Intended usage: 


Internet fax 
Color image scanning/rendering applications 
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- Author/Change controller: 

IETF 
A.14 MRC availability and mode 

- Media Feature tag name(s): 
MRC-mode 

- ASN.1 identifier associated with this feature tag: 
1.3.6.1.8.1.27 

- Summary of the media features indicated: 


This feature is used to indicate the availability of MRC 
(mixed raster content) image format capability, and also the 
MRC mode available. A zero value indicates MRC is not 
available, a non-zero value (in the range 1..7) indicates the 
available MRC mode number. 


An MRC formatted document is actually a collection of several 
images, each of which is described by a separate feature 
collection. An MRC-capable receiver is presumed to be capable 
of accepting any combination of contained images that conform 
to the MRC construction rules, where each such image matches 
the separately declared resolution, color capability, color 
model, image coding, and any other capabilities. 


NOTE: an MRC formatted document may appear within a 
TIFF image file structure. 


Within an MRC-formatted document, multi-level coders 
are used for foreground and background images (i.e. 


odd-numbered layers: 1, 3, 5, etc.) and bi-level coders 
are used for mask layers (i.e. even numbered layers 2, 
4, 6, etc.). 


- Values appropriate for use with this feature tag: 


Integer (0..7) 
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- The feature tag is intended primarily for use in the following 
applications, protocols, services, or negotiation mechanisms: 
Internet fax, and other applications that transfer image data. 
- Examples of typical use: 
See Appendix B of this document. 
- Related standards or documents: 
ITU T.44 [15] 
- Interoperability considerations: 
To establish the correct conditions for interoperability 
between systems, capabilities to handle the MRC mode and any 
contained image coding techniques must be established. 


- Related feature tags: 


image-coding [this document] 
MRC-max-stripe-size [this document] 


- Related media types or data formats: 
TIFF-FX [7] 
- Intended usage: 


Internet fax 
Color image scanning/rendering applications 


- Author/Change controller: 
IETF 
A.15 MRC maximum stripe size 
- Media Feature tag name(s): 
MRC-max-stripe-size 
- ASN.1 identifier associated with this feature tag: 


1.3.6.4 8.128 
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- Summary of the media features indicated: 


This feature may be used with MRC coding (MRC-mode>=1), and 
indicates the maximum number of scan lines in each MRC stripe. 


The value given indicates an upper bound on the stripe size. 
The actual value may vary between stripes, and the actual size 
for each stripe is indicated in the image data. 

- Values appropriate for use with this feature tag: 


Integer (>0) 


- The feature tag is intended primarily for use in the following 
applications, protocols, services, or negotiation mechanisms: 


Internet fax, and other applications that transfer image data. 
- Examples of typical use: 


(MRC-max-stripe-size<=256) 
(MRC-max-stripe-size>=0) 


- Considerations particular to use in individual applications, 
protocols, services, or negotiation mechanisms: 


For Internet fax, the legal constraints for an image receiver 
are those given as examples above. 


- Related feature tags: 
MRC-mode [this document] 
- Related media types or data formats: 
TIFF-FX [7] 
- Intended usage: 


Internet fax 
Color image scanning/rendering applications 


- Author/Change controller: 


IETF 
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Appendix B: TIFF mode descriptions 


This appendix contains descriptions of the TIFF modes defined by 
RFC 2301 [7], presented as feature set expressions in the form 
defined by "A syntax for describing media feature sets" [2] and 
using the feature schema introduced by this document. 


These may be taken as illustrations of the feature set combinations 
that are required for the corresponding TIFF profiles described by 
RFC 2301. 


TIFF-S has no optional elements, so is presented as a single 
feature set. Other profiles are presented as (TIFF-x-base) and 
(TIFF-x-full) indicating the minimum and full feature sets 
associated with each profile. 


(TIFF-S) :- 

(& (image-file-structure=TIFF-S) 

(color=Binary) 

(image-coding=MH) (MRC-mode=0) 

(| (& (dpi=200) 
(dpi-xyratio=[200/100,200/200]) 
(size-x=1728/200) ) 

(& (dpi=204) 
(dpi-xyratio=[204/98, 204/196] 
(size-x=1728/204) ) ) 
(paper-size=A4) ) 


(TIFF-F-base) :- 
(& (image-file-structure=TIFF-F) 
(color=Binary) 
(image-coding=MH) (MRC-mode=0) 
(dpi=204) 
(dpi-xyratio=[204/98,204/196]) 
(size-x=1728/204) 
(paper-size=A4) ) 
(TIFF-F-full) :- 
(4 (image-file-structure=TIFF-F) 
(color=Binary) 
(image-coding=[MH,MR,MMR]) (MRC-mode=0) 
(| (& (dpi=200) 
dpi-xyratio=[200/100,200/200]) 
size-x=[1728/200,2048/200,2432/200]) ) 


( 
( 

(& (dpi=204) 
(dpi-xyratio=[204/98,204/196,204/391]) 
(size-x=[1728/204,2048/204,2432/204]) ) 

(& (dpi=300) 
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dpi-xyratio=300/300) 
size-x=[2592/300,3072/300,3648/300]) ) 


(& (dpi=400) 
size-x=[3456/400,4096/400,4864/400]) ) 
(& (dpi=408) 


( 
( 
( 
(dpi-xyratio=400/400) 
( 
( 
( 


dpi-xyratio=408/391) 
(size-x=[3456/408, 4096/408,4864/408]) ) ) 
(paper-size=[A4, B4, A3, letter, legal]) ) 


(TIFF-J-base) :- 
(& (image-file-structure=TIFF-J) 

(color=Binary) 
(MRC-mode=0) 
(image-coding=JBIG) 
(image-coding-constraint=JBIG-T85) 
(JBIG-stripe-size=128) 
(dpi=204) 

(dpi-xyratio=[204/98,204/196]) 

(size-x=1728/204) 

(paper-size=A4) ) 


(TIFF-J-full) :- 
(& (image-file-structure=TIFF-J) 

color=Binary) 

MRC-mode=0) 

image-coding=JBIG) 

image-coding-constraint=JBIG-T85) 

JBIG-stripe-size>0) 

| (& (dpi=200) 
dpi-xyratio=[200/100,200/200]) 
size-x=[1728/200,2048/200,2432/200]) ) 


( 
( 
( 
( 
( 
( 


( 

( 

(& ( 
(dpi-xyratio=[204/98, 204/196, 204/391]) 
(size-x=[1728/204, 2048/204, 2432/204]) ) 
(dpi=300) 
(dpi-xyratio=300/300) 
(size-x=[2592/300, 3072/3000, 3648/300]) ) 
(dpi=400) 

(dpi-xyratio=400/400) 
(size-x=[3456/400,4096/400, 4864/4001) ) 
(dpi=408) 

(dpi-xyratio=408/391) 

(size-x=[3456/408, 4096/408,4864/408]) ) ) 
(paper-size=[A4, B4, A3, letter, legal]) ) 


(& 


(TIFF-C-base) :- 
(& (image-file-structure=TIFF-C) 
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(color=grey) 
(color-levels<=256) 

(MRC-mode=0) 

(image-coding=JPEG) (image-coding-constraint=JPEG-T4E) 
(color-space=CIELAB) 

(CIELAB-L-depth<=101) 

(CIELAB-L-min>=0) 

(CIELAB-L-max<=100) 

(color-illuminant=D50) 

(dpi=200) (dpi-xyratio=1) 

(size-x=864/100) 

(paper-size=A4) ) 


(TIFF-C-full) :- 
(& (image-file-structure=TIFF-C) 
(image-coding=JPEG) (image-coding-constraint=JPEG-T4E) 
(color-space=CIELAB) 
(| (& (color=grey) 
(color-levels<=4096) 
(CIELAB-L-depth<=4096) ) 

(& (color=full) 
(color-levels<=68719476736) 
(color-subsampling=["4:1:1","1:1:1"]) 
(CIELAB-L-depth<=4096) 
(CIELAB-a-depth<=4096 

(CIELAB-b-depth<=4096 
MRC-mode=0) 
dpi=[100,200,300,4001) (dpi-xyratio=1) 
size-x=[864/100,1024/100,1216/100]) 
paper-size=[A4, B4, A3, letter, legal]) ) 


) 
))) 


( 
( 
( 
( 


(TIFF-L-base) :- 

(& (image-file-structure=TIFF-L) 
(MRC-mode=0) 
(image-coding=JBIG) 
(image-coding-constraint=JBIG-T43) 
(JBIG-stripe-size=128) 
(image-interleave=stripe) 
(color=grey) 
(color-levels<=256) 
(color-space=CIELAB) 
(CIELAB-L-depth=101) 
(CIELAB-L-min>=0) 
(CIELAB-L-max<=100) 

(color-illuminant=D50) 
(dpi=200) (dpi-xyratio=1) 
(size-x=864/100) 
(paper-size=A4) ) 
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(TIFF-L-full) :- 

(& (image-file-structure=TIFF-L) 
MRC-mode=0) 
image-coding=JBIG) 
image-coding-constraint=JBIG-T43) 
JBIG-stripe-size>0) 
image-interleave=[stripe, plane]) 
| (& (color=limited) 
(color-levels<=8) 
(color-space=[Device-RGB, Device-CMY] ) ) 
(color=limited) 
(color-levels<=16) 
(color-space=Device-CMYK) ) 
(color=mapped) 
(color-levels<=65536) 
(color-space=CIELAB) 
(CIELAB-L-depth<=4096) 
(CIELAB-a-depth<=4096) 
(CIELAB-b-depth<=4096) ) 
( 
( 
( 
( 
( 
( 
( 
( 
( 
( 


( 
( 
( 
( 
( 
( 


(& 


color=grey) 

color-levels<=4096) 
color-space=CIELAB) 
CIELAB-L-depth<=4096) ) 
color=full) 

color-space=CIELAB) 
color-levels<=68719476736) 
CIELAB-L-depth<=4096) 
CIELAB-a-depth<=4096) 
CIELAB-b-depth<=4096) 
(CIELAB-L-min>=0) ) ) 
(dpi=[100,200,300,400]) (dpi-xyratio=1) 
(size-x=[864/100,1024/100,1216/100]) 
(paper-size=[A4, B4, A3, letter, legal]) ) 


(TIFF-M-base) :- 
(& (image-file-structure=TIFF-M) 
(MRC-mode>=1) 
(MRC-max-stripe-size<=256) ) 


(TIFF-M-full) :- 


(& (image-file-structure=TIFF-M) 
(MRC-mode>=1) ) 
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Support for multiple TIFF profiles may be indicated by combining 
their expressions with the OR operator; e.g. 


(| (TIFF-F) (TIFF-S) (TIFF-J) ) 
indicates support for all black-and-white modes. 


TIFF-M is a composite mode and must be used in conjunction with 
some other mode to define the particular capabilities of a 
receiver; e.g. 


(| (TIFF-M-base) 
(TIFF-S) (TIFF-J-full) (TIFF-C-base) (TIFF-L-full) ) 


Each sub-image in an MRC image must conform to the capabilities 
indicated AND also to any additional constraints imposed by the MRC 
structure, such as bi-level mask layer, etc. See sections A.13 and 
section 3.7. 
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Appendix C: Changes from RFC 2531 


00a 23-Jun-1999 


00b 10-Aug-1999 


Ola 01-Oct-1999 


0lb 05-Jan-2000 


Klyne & McIntyre 


Updated Appendix B with more complete TIFF-FX 
profile descriptions. Added note to section 3.5 
clarifying the meaning of (color=limited) in the 
context of Internet fax. Added note to section 
3.6 and A.6 to clarify interpretation of color 
depth. In A.6, noted that color gamut is not the 
same as color resolution; fixed example. Split 
section 3.7 into two sections, dealing with simple 
image coding options and MRC composite image 
options. Added new feature tag ’color-illuminant’ 
(sections 3.6, A.5). Added cross-references from 
TIFF-M image file structure to MRC-mode tag. 
Updated introduction and references. 


Bring examples into line with T.30 mapping 
document [4], and reorganize to make the 
expression structure less complex. Add details of 
mailing list for discussion. Added JPEG-only 
colour example. Change definition of image-file- 
structure tag to indicate more precisely what is 
being defined, and to draw out the distinction 
between a file structure to contain MRC images 
(image-file-structure), and the MRC image model 
(MRC-mode) . 


Update author’s address and some references. 


Incorporate last-call review comments (all 
editorial). 
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or assist in its implementation may be prepared, copied, published 
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kind, provided that the above copyright notice and this paragraph are 
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The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
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